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ABSTRACT 



A distributed computer system has a number of comput- 
ers coupled thereto at distinct nodes. The computer at 
each node of the distributed system has a trusted com- 
puting base that includes an authentication agent for 
authenticating requests received from principals at 
other nodes in the system. Requests are transmitted to 
servers as messages that include a first identifier pro- 
vided by the requester and a second identifier provided 
by the authentication agent of the requester node. Each 
server process is provided with a local cache of authen- 
tication data that identifies requesters whose previous 
request messages have been authenticated. When a re- 
quest is received, the server checks the request's first 
and second identifiers against the entries in its local 
cache. If there is a match, then the request is known to 
be authentic. Otherwise, the server node's authentica- 
tion agent is called to obtain authentication credentials 
from the requester's node to authenticate the request 
message. The principal identifier of the requester and 
the received credentials are stored in a local cache by 
the server node's authentication agent. The server pro- 
cess also stores a record in its local cache indicating that 
request messages from the specified requester are 
known to be authentic, thereby expediting the process 
of authenticating received requests. 

9 Claims, 5 Drawing Sheets 
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known to be autbenic, without having to obtain authen- 

AOCESS CONTROL SUBSYSTEM AND METHOD tication credentials from the requester's node, because 

FOR DISTRIBUTED COMPUTER SYSTEM USING the authentication agents guarantee authenticity of such 

LOCALLY CACHED AUTHENTICATION request messages. 

CREDENTIALS 5 If the identifier in a request message does not match 

any of the entries in the server's local cache, then the 

The present invention relates generally to controlling server node's authentication agent is called to obtain 

access to computer resources in a distributed computer authentication credentials from the requester's node to 

system, and particularly to apparatus and methods for authenticate the request message. Upon receiving the 

making such access control systems more efficient by 10 required credentials from the requester node's authenti- 

localty caching in each computer authentication ere* cation agent, the principal identifier of the requester and 

dentials for principals requesting use of that computer's the received credentials are stored in a local cache by 

resources. the server node's authentication agent. The server pro- 

PArir rtpmrwn op tot Twrnsmnw ^ also stores a rccord m its local °* ch * indicating that 

BACKGROUND OF THE INVENTION l5 request messages from the specified requester are 

Computer security systems are often based on the known to be authentic, thereby expediting the process 

basic access control model, which provides a founda- of authenticating received requests, 
tion for secrecy and integrity security procedures. See, A further optimization is that the server process local 

for example, the 1974 article by Butler Lampson, cache is used to store a list of the object access control 
"ACM Operating System Reviews," Vol. 8, No. 1, 20 list entries previously satisfied by each requester, 

January 1974, pp. 18-24. The elements of this model thereby enabling the server process to expedite granting 

are: access to previously accessed objects. 
Objects, which are resources such as files, devices, or ^^ 0 ^„ TTVT , T ^^ T ^, T1 _ A „ 

processes. BRIEF DESCRIPTION OF THE DRAWINGS 

Requests to perform operations on objects. 25 Additional objects and features of the invention will 
Sources for requests, which are principls. be more readily apparent from the following detailed 
A reference monitor that examines each request for description and appended claims when taken in con- 
access to a specified object and decides whether to junction with the drawings, in which: 
grant it. FIG. 1 is a block diagram a distributed computer 
The reference monitor bases its decision on the ob- 30 system with a trusted naming service for storing secure 
ject, the principal making the request, the operation in data shared by the members of the system, 
the request, and a rule that says what principals may FIGS. 2 and 3 are block diagrams of one node of the 
perform that operation. It should be understood that distributed computer system shown in FIG. 1. 
operation of the reference monitor is separate and dis- FIG. 4 is a block diagram of two computers, one 
tinct from other security issues, such as whether a re- 35 having a requester process that is requesting access to a 
questor is who he/she/it claims to be. That type of server process in the second computer, 
security is typically provided by using encryption and FIGS. 5A and 5B schematically depict an Authenti- 
digital signature techniques, sometimes called authenti- cation ID table and Channel Assignment Table main* 
cation, as will be understood by those skilled in the art. tained by authentication agents in the preferred embodi- 
The present invention is directed at a technique for 40 ment of the present invention, 
making authentication of requesters more efficient. FIG. 6 schematically represents a data packet. 

In general, in most prior art systems authenticating FIG. 7 schematically depicts a "local cache" of au- 

each request by a requester requires digitally signing the thentication data maintained by authentication agents in 

request, as well as an exchange of information called the preferred embodiment of the present invention, 

"credentials" between the requester and the server to 45 FIG. 8 schematically depicts a local cache of authen- 

enable the server to authenticate the digital signature on tication data maintained on behalf of each server pro- 

the request. The authentication process can impose cess in the preferred embodiment of the present inven- 

significant overhead on the operation of distributed tion. 

computer systems, especially when the number of re- FIG. 9 is a block diagram representing an access 

quests transmitted between nodes is high. 50 control list. 

, m a M ^ r „_ ,^ w ,^ t FIG. 10 is a flow chart of the authentication process 

SUMMARY OF THE INVENTION performed by the authentication agents associated with 

In summary, the present invention is a security sys- a requester and a server. 



DESCRIPTION OF THE PREFERRED 



tern governing access to objects in a distributed com- 
puter system. The computer at each node of the distrib- 55 , ^ i w , ™™ 
uted system has a trusted computing base that includes fcMtfUDlMfcN i 
an authentication agent for authenticating requests re* Referring to FIG. 1, the present invention is a secu- 
ceived from principals at other nodes in the system. rity system and method which typically operates in the 
Requests are transmitted to servers as messages that context of a distributed computer system 100 having a 
include a first identifier (called an Auth ID) provided 60 set of computers 102-1 to 102-N interconnected by a 
by the requester and a second identifier provided local or wide area network 110 or some other communi- 
(called the subchannel value) by the authentication cations medium. Each of these computers 102 is said to 
agent of the requester node. Each server process has an be located at a distinct node of the distributed computer 
associated local cache that identifies requesters whose system 100. 

previous request messages have been authenticated. 65 For the purposes of this document, we assume that 

When a request is received, the server checks the re- the nodes are connected to each other by wires that are 

quest's first and second identifiers against the entries in not physically secure. In the preferred embodiment, 

its local cache. If there is a match, then the request is shared key encryption is used to secure channels be- 
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tween the nodes of the distributed system, and these tion, decryption, and digital signatures and the like are 

channels are then multiplexed to obtain all the other not the subject of this document. These topics are 

channels needed by the network. Since the operating widely discussed in the computer security literature, 

system at each node must be trusted anyway, using The present invention primarily concerns the authenti- 

encryption at a finer grain than this (e.g., between pro- 5 cation agent 134 and reducing the exchange of creden- 

cesses) is not necessary. Alternately, public key encryp- tials associated with authenticating messages sent be- 

tion techniques could be used to secure the channels tween requesters and servers on different nodes of the 

between nodes, although public key encryption is usu- distributed computer system. 

ally much slower than shared key encryption. For the purposes of FIG. 3, a process Al in node 

Each computer 102 contains the standard computer 10 102-2 has been labelled "requester" because it is sends a 

system components, including a data processing unit request to one of the server processes Bl to BN on node 

(CPU) 112, system bus 114, primary (random access) 102-1. However, it should be noted that more generally 

memory 116, secondary storage 118 (e.g., magnetic or the requester can be a principal using any one of the 

optical disks), virtual memory manager 120, a user inter- computers in the distributed system, 

face 122 (e.g., keyboard, monitor and printer) and net- IS A principal is herein defined to be the source of a 

work controller 124 for coupling the computer 102 to request or assertion. Typically, one thinks of a principal 

the network 110. A clock circuit 126 or equivalent as a person, or a machine acting on behalf of a person, 

mechanism provides each computer 102 with time val- However, processes many layers removed from human 

ues (used by the security apparatus discussed below). direction, such as those in a transaction processing sys- 

The physical computer components are not modified by 20 tern, can also be principals. 

the present invention and are therefore not described in Objects can be files, processes, set of data such as 

detail herein. table or database, programs (e.g., an interface program 

For convenience of schematic representation, the which governs use of an input/output device), and so 

computer's operating system 130 is shown in FIG. 2 as on. In the preferred embodiment, the objects 136 to 

being stored in primary memory, but as will be under- 25 which access is governed by the reference monitor 

stood by those skilled in the art, portions of the operat- program 132 on node 102-1 are stored in the computer 

ing system 130 are stored by the computer's virtual at that node (other arrangements may be possible). Each 

memory manager 120 in secondary memory when not object 136 includes an Access Control List (ACL) 138 

in use. The operating system 130 includes a reference which defines the set of "principals" who are autho- 
monitor 132 and authentication agent 134, both of 30 rized to access the object 136. 

which are discussed in more detail below. Referring to FIG. 4, each node of the distributed 

Also shown in FIG. 2 is the (virtual) memory alio- system includes in its TCB an authentication agent 134. 

cated to two processes, Bl and B2, including applica- In the context of FIG. 4, we will consider the actions of 

tion programs as well as data structures and software the authentication agent 134 associated with process Al 

associated with the present invention. As will be under- 35 on node 102-2 sending a request to a server process Bl 

stood by those skilled in the art, while the memory on node 102-1. 

space allocated to these processes is shown for conve- Prior to the sending of any requests between two 

nience as being in primary memory, much of the mem- nodes, a secure channel 140 between the two nodes 

ory space allocated to each process will be stored by the must be established. One method of establishing a se- 

computer's virtual memory manager 120 in secondary 40 cure channel between two nodes is to have the two 

memory when not in use. nodes establish a host-to-host key that will be used both 

Referring to FIG. 3, one node 102-1 of the distributed to encrypt and decrypt all data packets transmitted 
system is shown in more detail. Each node must have a between the two nodes. Data packets in the preferred 
trusted computing base (TCB) 135, which is typically a embodiment are encrypted using a private key encryp- 
small amount of computer hardware and software that 45 tion methodology, such as DES CBC. 
security depends on and that is distinguished from the The prior art provides any number of mechanisms for 
remainder of the node, which can misbehave without distributing encryption keys in a network. One such 
affecting security. The TCB 135 includes a reference methodology developed at the Massachusetts Institute 
monitor program 132 (sometimes called the reference of Technology is known as KERBEROS. Other meth- 
monitor), which gathers the information needed to jus- 50 odologies are known as public key systems. In any case, 
tify an access control decision. The reference monitor in the context of the present invention, any two host 
program 132 runs within the address space of each computers that will transmit data packets therebetween 
process. The TCB 135 also includes an authentication must first agree on a "host-to-host" encryption key that 
agent 134, which in the present invention is a set of will used to encrypt the secure portions of data packets 
software in the computer's operating system that ex- 55 transmitted between those two computers. Further- 
changes credentials with the authentication agents of more, to ensure data integrity, a CRC error detection 
other nodes so as to authenticate the source of request code is included in each data packet, usually at the end 
messages. The authentication agent 134 also performs a of the data packet, for detecting corrupted packets as 
number of related tasks to ensure that messages origi- well as for detecting packets that may have been tam- 
nated by processes at its node are tagged or signed with 60 pered with in an attempt to break the system's security 
valid sender identification data, as will be described provisions. Therefore each packet received by a node's 
below. network controller 124 must be decrypted and error 

The TCB 135 does not include the storage devices checked by a CRC (cyclic redundancy check) circuit 

from which data is retrieved nor the transmission chan- before it can be used by the receiving host computer 

nels from which messages are received. This is because 65 102. 

digitally signed messages can be fetched from unse- Once a secure channel 140 has been established, all 

cured places without any loss of confidence that the data packets sent over the secure channel 140 by either 

signer actually sent it originally. The details of encryp- node are routed through the sender's authentication 
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agent 134. The authentication agent 134 assigns a differ- 
ent virtual "subchannel" of the secure channel to each 
requester/server process pair for which a requester 
process on the authentication agent's node transmit data 
packets to a server process on the other node. Subchan- 5 
nels are similar to process-to-process communication 
channels found in traditional operating systems* For 
example the Internet Transmission Control Protocol 
provides a bi-directional connection between two pro- 
cesses. However, in the present invention subchannels 10 
are implemented on top of node-to-node secure chan- 
nels and authenticity guarantees can be made about the 
data which traverses them. Any given subchannel has 
two unique endpoints. The authentication agent at each 
endpoint guarantees the uniqueness of the endpoint it IS 
controls. Therefore, since an underlying node-to-node 
channel is implied, each endpoint can believe that all 
data received through the subchannel originated at the 
unique node and process associated with the other end- 
point of that subchannel. 20 

In the preferred embodiment, each principal associ- 
ated with the node 102 is assigned a distinct authentica- 
tion identifier, herein called the Auth ID. Typically, the 
assignment of the Auth ID to a principal is performed at 
the time that the principal logs into the system. It is 25 
possible for a single process Al to do work on behalf of 
multiple principals, in which case each principal associ- 
ated with the process will be given a distinct Auth ID. 

Each node's authentication agent 134 maintains an 
Auth ID table 142, shown in FIG. 5A, which lists the 30 
name of the principal and its assigned Auth- ID. Each 
record in the table would typically also include other 
information, such as the name of the process that the 
principal is logged onto. 

Each node's authentication agent 134 also maintains a 35 
Channel Assignment table 144, shown in FIG. SB, 
which lists for each communication subchannel that has 
been assigned to a process, identifiers associated with 
the channel, subchannel, requester process and server 
process for which the subchannel is being used. 40 

Referring to FIG. 6, each data packet 146 transmitted 
between nodes includes items provided by the process 
sending the data packet, and at least one field whose 
value is provided by the authentication agent. In partic- 
ular, the requester process will typically generate a data 45 
packet 146 that includes destination data 148, a field 150 
containing the alleged Auth ID of the principal on 
whose behalf the data packet is being sent, plus other 
packet header data 152 and the packet body 154. The 
destination data 148, whether included in the data 50 
packet or provided separately by the sending process, 
identifies the server node and process to which the data 
packet is being sent. For instance, the destination data 
148 may comprise a node identifier and a process identi- 
fier. 55 

The authentication agent adds a subchannel value 156 
to the data packet 146 that corresponds to the requester 
and server processes. If no subchannel has previously 
been assigned to this pair of processes, a unique sub- 
channel value is assigned and a new entry is added to 60 
the channel assignment table 144, and then the assigned 
subchannel value is added to the data packet. If a sub- 
channel has previously been previously been assigned to 
this pair of processes, the assigned subchannel is ob- 
tained from the channel assignment table 144 and then 65 
added to the data packet 146. The subchannel value 
field 156 uniquely identifies the secure channel over 
which the packet will be sent, in addition to identifying 



the sending and receiving processes. Therefore, directly 
or indirectly, the subchannel field 156 includes a chan- 
nel identifier. For instance, the subchannel field may 
contain a value used by the receiving node's network 
controller to determine which decryption key to use for 
decrypting the data packet. 

Local Auth ID Cache for Authentication Agent. 
When a request message is sent from a requester princi- 
pal to a server process, the authenticity of each request 
must be verified. The present invention modifies prior 
art authentication procedures by maintaining two types 
of "local caches" 160 and 164 (actually tables of data 
stored in memory) which identify requesters whose 
previous request messages were authenticated. The 
local cache 160 for the authentication agent lists the 
channel, subchannel and Auth ID of each principal 
from whom messages have been received. The record 
162 in the local cache 160 for each such principal also 
includes a principal identifier, credentials received from 
the principal's host computer that authenticate the prin- 
cipal's messages, and a timestamp indicating a time limit 
on the validity of those credentials. 

When a message from a principal is authenticated, a 
set of several credentials are sent to authenticate the 
message, include credentials authenticating the node, 
and credentials specific to the user. Each such creden- 
tial has an associated time limit that limits the validity of 
that credential. When an authentication agent receives a 
set of credentials for a particular requester, it stores in 
the corresponding record 162 a timestamp representing 
the shortest duration time limit associated with the re- 
ceived credentials. That is, each received credential is 
delivered with a time limit (e.g., a datum indicating that 
the corresponding credential is valid for N seconds), 
and the authentication agent converts those time dura- 
tion limits into a time value to be compared during later 
attempts to use the record 162 with the computer's 
current time value (maintained by the computer in con- 
junction with its clock circuit 126). 

Local Auth ID Cache for Server Processes. In the 
preferred embodiment, each server process maintains a 
local cache 164 in its own address space. As shown in 
FIG. 8, each record 166 of the server process local 
cache identifies a requester principal from whom a re- 
quest was previously received, the requester's Auth ID 
and the subchannel over which request messages from 
that requester have been received, a timestamp indicat- 
ing a time limit on the validity of the local cache entry, 
as well a list of the object ACL entries which the re- 
quester principal is known to satisfy. 

As mentioned before, each object has an associated 
access control list (ACL). Typically, each ACL 136 
contains a list of entries, each of which indicates the 
type of access allowed for a specified principal. As 
shown in FIG. 9, an object's ACL 136 consists of a set 
of entries 170 for each distinct type of access associated 
with the object. For instance, if an object is a set of data, 
it is possible or even likely that some principals might 
have only read access while other principals are al- 
lowed both read and write access. Each entry 170 de- 
fines one principal or compound principal who is autho- 
rized to access the object. 

The concept of compound principals allows for virtu- 
ally unlimited complexity in defining a requester or 
defining a party authorized to access an object. Com- 
pound principals, and their use in computer access con- 
trol systems, are discussed extensively in pending patent 
applications Ser. No. 07/589,923, filed Sep. 28, 1990, 
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entitled Compound Principals in Access Control Lists, 
and Ser. No. 07/783,361, filed Oct. 28, 1991, entitled 
Access Control Subsystem and Method for Distributed 
Computer System Using Compound Principals, both of 
which are hereby incorporated by reference. 5 

Authenticating Requests. Referring to the flow chart 
in FIG. 10, whenever a request message is transmitted 
to a server process at another node, the receiving node 
identifies the requester in terms of the channel over 
which the data packet was transmitted, plus the sub- 10 
channel and Auth ID fields 156 and 150 in the data 
packet. Note that the while subchannel field 156 in the 
preferred embodiment includes both channel and sub- 
channel values, in other embodiments the channel 
might be identified in other ways, with the resulting 15 
channel value being passed to the server process along 
with the received data packet. In either case, it is the 
responsibility of the server process to ensure that the 
subchannel value in the received message corresponds 
to the actual secure channel over which the request was 20 
received. 

In the preferred embodiment, the requester process 
creates the request message (step 200), including an 
alleged Auth ID value, and the authentication agent 
adds the channel and subchannel information to the 25 
corresponding data packet (step 202), based on the iden- 
tities of the requester and server processes between 
which the data packet is being transmitted, before trans- 
mitting the request message data packet to the node 
associated with the requester server. Assuming that the 30 
packet arrives uncormpted at its specified destination 
node, the data packet is delivered into the address space 
of the specified server process (step 204), for example 
process Bl of node 102-1. The server process Bl then 
checks its local cache 164 to see there is already an 35 
entry for the requester, as identified by the "channel, 
subchannel, Auth ID" values associated with the re- 
ceived data packet (step 206). 

If the requester is not listed in the server's local cache 
164, or if the entry 166 for the requester is no long valid 40 
(as determined by comparing the timestamp value in the 
entry 166 with a current time value (maintained by the 
computer in conjunction with its clock circuit 126), 
then the server process requests the authorization agent 
134 for its node to authenticate the request message 45 
(step 208). Since the authentication agent 134 for the 
server's node may already have received credentials for 
the requester in a previous transaction, it looks for a 
record in its local cache matching the requester mes- 
sage's channel, subchannel and Auth ID (step 210). If 50 
the authentication agent's local cache 160 contains a 
record matching the channel, subchannel, and subchan- 
nel associated with the received message, and the times- 
tamp value indicates that the record 162 for the re- 
quester is still valid, that means the request message is 55 
"pre-authenicated", in which case the authentication 
agent notifies the server process that the request mes- 
sage is authentic (step 212) and passes to the server 
process the timestamp and (optionally) the Principal ID 
for the requester. By including the Principal ID of the 60 
requester in the server process' local cache 164, access- 
ing objects using the requester's Principal ID is made 
more efficient. 

If the requester's Auth ID in not found in the authen- 
tication agent's local cache 160, then the authentication 65 
agent sends a request to the authentication agent of the 
requester's node for credentials to authenticate the re- 
quest message (step 214). The authentication agent of 
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the requester's node checks the authenticity of the 
"channel, subchannel, Auth ID" values associated with 
the request message. The first step of this checking 
process is searching its channel assignment table 144 for 
the request process associated with the request mes- 
sage's channel and subchannel. The second step is 
searching the Auth ID Table 142 to see if the specified 
Auth ID value is assigned to a principal logged onto the 
process found in the channel assignment table 144. If the 
authentication agent determines that the "channel, sub- 
channel, Auth ID" values associated with the request 
message are valid, then it sends to the authentication 
agent in the server node the Principal ID for the re- 
quester, plus the required credentials, using digital sign- 
ing protocols well known to those skilled in the art, 
thereby authenticating the request message (step 215). If 
the requester node authentication agent determines that 
the "channel, subchannel, Auth ID" values associated 
with the request message are not valid, it sends a nega- 
tive acknowledgement (nak message) back to the server 
node's authentication agent, which will then void the 
request message. 

Upon receipt of the required credentials, the server 
node's authentication agent stores the credentials in a 
record 162 in its local cache 160 and notifies the server 
process that the request message is authentic (step 212). 
The server process then adds a record 166 to its local 
cache 164 for the requester associated with the now- 
authenticated request message and proceeds with exe- 
cution of the requested tasks (step 216). 

Returning to step 206, if the requester is listed in the 
server's local cache 164, and the timestamp for the 
requester indicates that the previously received creden- 
tials for this requester are still valid, the server process 
proceeds with execution of the requested tasks (step 
218). During execution of these tasks, if the server pro- 
cess successfully gains access to any objects on behalf of 
the requester, the ACL entries satisfied by the requester 
are added by the server process to the requester's re- 
cord in the server process's local cache (step 220). The 
storage of ACL entries known to be satisfied by a par- 
ticular requester in the server's local cache can be used 
by the server process to expedite granting access to 
previously accessed objects. 

The authentication agent 143 for each node will peri- 
odically check its local cache 160 for records with ex- 
pired credentials, so that such records can be deleted, 
along with the corresponding records in the server 
process local caches. 

While the present invention has been described with 
reference to a few specific embodiments, the descrip- 
tion is illustrative of the invention and is not to be con- 
strued as limiting the invention. Various modifications 
may occur to those skilled in the art without departing 
from the true spirit and scope of the invention as defined 
by the appended claims. It should be noted that the 
authentication agent can be considered to be an abstrac- 
tion representing various portions of an operating sys- 
tem, or even various secure programs, such as trusted 
applications, that run on top of the operating system, 
that performs the security functions of the above de- 
scribed invention. 

What is claimed is: 

1. In a distributed computer system having a multi- 
plicity of interconnected computers, security apparatus 
comprising: 

a plurality of processes, each process running on one 
of said multiplicity of computers, said plurality of 
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processes including requester processes and server 
processes; 

secure channels connecting ones of said multiplicity 
of computers on which respective ones of said 
requester processes are running to second ones of 5 
said multiplicity of computers on which respective 
ones of said server processes are running; and 

a multiplicity of authenticating agents, each running 
in a trusted computing base on a different one of 
said multiplicity of interconnected computers; 10 

one of said multiplicity of authenticating agents, run- 
ning on one of said multiplicity of computers hav- 
ing at least one server process running thereon, 
including: 

local cache means for maintaining data identifying 15 
previously authenticated requests from ones of 
said requester processes running on other ones of 
said multiplicity of interconnected computers; 
and 

received request authenticating means for authenti- 20 
eating, on behalf of said at least one server pro- 
cess, a received request when data in said re- 
ceived request match said data maintained by 
said local cache means, for obtaining credentials 
authenticating said received request when said 25 
first data in said received request does not match 
said data maintained by said local cache means, 
and for enabling said at least one server process 
to process said received request only after said 
received request has been authenticated. 30 

2. The security apparatus of claim 1, wherein . 
each requester process includes means for generating 

a request and for initiating transmission of said 
request over one of said secure channels to a speci- 
fied one of said server processes; and 35 
each server process includes 
cache means for maintaining its own local cache of 
data identifying previously authenticated re- 
quests received by said server process; and 
local authenticating means for authenticating a 40 
received request when said first data in said re- 
ceived request matches said data maintained by 
its own cache means, and for requesting authen- 
tication of said received request by said authenti- 
cation agent running on the same computer as 45 
said server process when said data in said re- 
ceived request does not match said data main- 
tained by its own cache means. 

3. The security apparatus of claim 1, wherein 

said local cache means includes means for time limit- 50 
ing validity of said data identifying previously au- 
thenticated requests; 

said received request authenticating means including 
means for not matching data in said received re- 
quest match with invalid data in said local cache 55 
means. 

4. In a distributed computer system having a multi- 
plicity of interconnected computers, security apparatus 
comprising: 

a plurality of processes, each process running on one 60 
of said multiplicity of computers, said plurality of 
processes including requester processes and server 
processes; 

secure channels connecting first ones of said multi- 
plicity of computers on which respective ones of 65 
said requester processes are running to second ones 
of said multiplicity of computers on which respec- 
tive ones of said server processes are running; 
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a plurality of authenticating agents, each running in a 
trusted computing base on a different one of said 
multiplicity of interconnected computers; 

each requester process including means for generat- 
ing a request and for initiating transmission of said 
request over one of said secure channels to a speci- 
fied one of said server processes, said request in- 
cluding a first datum allegedly identifying a princi- 
pal associated with said requester process; 

each authenticating agent running on one of said 
multiplicity of interconnected computers having at 
least one requester process running thereon includ- 
ing: 

request processing means for adding a second 
datum to each request generated by a requester 
process running on the same one of said multi- 
plicity of computers as said authenticating agent, 
wherein said second datum uniquely corre- 
sponds to said originating requester process; and 
request authenticating means for authenticating 
that the first datum and second datum in a previ- 
ously sent request are valid; 
each authenticating agent running on one of said 
multiplicity of interconnected computers having at 
least one server process running thereon including: 
local cache means for maintaining data indicating 
said first datum and second datum in previously 
authenticated requests; and 
received request authenticating means for (A) au- 
thenticating, on behalf of said at least one server 
process, a received request when said first datum 
and second datum in said received request match 
said data maintained by said local cache means, 
(6) obtaining authentication of said received 
request from said authenticating agent running 
on the same computer as the requester process 
that sent said received request when said first 
datum and second datum in said received request 
do not match said data maintained by said local 
cache means, and (C) enabling said at least one 
server process to process said received request 
only after said received request has been authen- 
ticated. 

5. The security apparatus of claim 4, wherein 
each server process includes 

cache means for maintaining its own local cache of 
data indicating said first datum and second 
datum in previously authenticated requests re- 
ceived by said server process; and 

local authenticating means for authenticating a 
received request when said first datum and sec- 
ond datum in said received request match said 
data maintained by its own cache means, and for 
requesting authentication of said received re- 
quest by said authentication agent running on the 
same computer as said server process when said 
first datum and second datum in said received 
request do not match said data maintained by its 
own cache means. 

6. The security apparatus of claim 4, wherein 

said local cache means includes means for time limit- 
ing validity of said data identifying previously au- 
thenticated requests; 

said received request authenticating means including 
means for not matching data in said received re- 
quest match with invalid data in said local cache 
means. 
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7. A method of operating a distributed computer 
system having a multiplicity of interconnected comput- 
ers, the steps of the method comprising: 
running requester processes on at least a first subset of 
said multiplicity of computers and running server 5 
on at least a second subset of said multiplicity of 
computers; 

interconnecting with secure channels first ones of 
said multiplicity of computers on which respective 
ones of said requester processes are nmning to 10 
second ones of said multiplicity of computers on 
which respective ones of said server processes are 
running; 

establishing authenticating agents within a trusted 
computing base on each one of said multiplicity of 15 
computers; 

said requester processes each generating requests and 
initiating transmission of said requests over ones of 
said secure channels to specified ones of said server 
processes, said requests each including a first 20 
datum allegedly identifying a principal associated 
with said each requester process; 

said authenticating agents adding to each request 
generated by said requester processes a second 
datum uniquely corresponding to the one of said 25 
requester processes which generated said each 
request; and 

those of said authenticating agents established on 
ones of said multiplicity of computers having at 
least one server process running thereon (A) main- 30 
taining a local cache of data indicating said first 
datum and second datum in previously authenti- 
cated requests received by said at least one server 
process, and (B) authenticating, on behalf of said at 
least one server process, a received request when 35 



,642 

12 

said first datum and second datum in said received 
request match said data in said local cache, (C) 
obtaining authentication of said received request, 
from said authenticating agent established on the 
computer running the requester process that sent 
said received request, when said first datum and 
second datum in said received request do not 
match said data maintained by said local cache 
means, and (D) for enabling said at least one server 
process to process said received request only after 
said received request has been authenticated. 

8. The method of claim 7, 

each server process maintaining its own local cache 
of data indicating said first datum and second 
datum in previously authenticated requests re- 
ceived by said server process; and 
each server process self-authenticating a received 
request when said first datum and second datum in 
said received request match said data maintained 
by its own cache means, and requesting authentica- 
tion of said received request by said authentication 
agent nmning on the same computer as said server 
process when said first datum and second datum in 
said received request do not match said data main- 
tained by its own cache means. 

9. The method of claim 7, 

said authentication agents time limiting validity of 
said data maintained in said local cache for each 
said previously authenticated request; 
said authentication agents for not authenticating, on 
behalf of said at least one server process, a received 
request when said first datum and second datum in 
said received request match invalid data in said 
local cache. 

***** 
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